Феанор как harness — рамка развития

Контекст: обзор Lilian Weng (июль 2026) систематизирует «harness engineering» — слой между моделью и реальным миром, который решает, как агент думает, зовёт инструменты, помнит, проверяет себя и улучшается. Феанор ровно это и есть. Статья даёт язык и чек-лист для его развития. Это не про сегодняшний фикс хуков — это про феанора целиком.

Главная мысль статьи: прогрессия объекта оптимизации — промпт → структурный контекст → workflow → код харнесса → код оптимизатора. Чем умнее база (у нас Opus — достаточно мощная, статья предупреждает: слабая модель при само-улучшении деградирует), тем к более общим механизмам и дальше по этой цепочке можно двигаться. Феанор сейчас где-то между «workflow» и «код харнесса».

Что феанор уже делает правильно (по статье)

• File system as memory (Pattern 2): Strategy/, CLAUDE.md, MEMORY.md, .claude/rules/, data/*.jsonl. Долгосрочное знание — в файлах, не в контексте. Это фундамент, статья на нём настаивает.
• Sub-agents & backend jobs (Pattern 3): Agent, Workflow, Pulse как процесс-менеджер; артефакты в worker_output.jsonl, long_run.json — состояние переживает перезапуск.
• Workflow automation (Pattern 1): Pulse — goal-oriented loop (оценить → важное → сделать/предложить → лог).
• Feedback→mutation (≈ Self-Harness stage 2): feedback_to_mutation.py → feedback_queue.jsonl → эволюционный слот Pulse; skill_evolve.py («bounded edit→gate»). Это уже bounded proposal — редкость.
• Permission вне модели (безопасность): PreToolUse-хуки как железное принуждение (Co-Authored-By, materials.yml, restart, Groq-для-LLM). Статья: security-слой должен жить ВНЕ цикла эволюции — у нас так.
• Гигиена системы: script_reachability.py убирает мёртвый код — «keep the system sustainable».
• Anti-fabrication gate: прямо бьёт по failure mode «bias toward training-data defaults» из статьи.

Вывод: архитектурно феанор — уже зрелый harness, а не «промпт + инструменты». Дальше — не переписывать, а закрывать точечные пробелы в петле самоулучшения.

Пробелы и что взять (по слоям)

1. Слой самоулучшения — нет валидационного контура (главное)

Статья описывает Self-Harness как строгий цикл: weakness mining → bounded proposal → validation. У феанора есть первые две стадии, третья слабая. Правка машинерии («edit→gate») не проверяется на то, что не сломала другое поведение. Held-in + held-out регрессия — ключевое требование статьи: правку мержить, только если нет регрессии на обоих.

Что взять: набор «золотых» проверок машинерии феанора (хуки отрабатывают в обеих средах мак+VPS; Pulse не падает в dry-run; MCP коннектятся; status.sh зелёный), которые эволюционный слот прогоняет ПЕРЕД тем как объявить мутацию принятой. Это автоматизирует ручной труд, который сейчас делаем каждый раз руками.

2. Слой памяти о фейлах — нет rich failure records + negative results

Статья (weakness mining): две ошибки с одним симптомом (timeout, missing artifact) могут иметь разные корни — нужна запись терминальная причина + причинный статус поведения + абстрактный механизм. И (Future Challenges №3): фейлы и отклонённые кандидаты сохранять, не выбрасывать — «learning from failure is the best way to trim the search space». У феанора evolution_log копит успехи, но структурного лога обломов Pulse и отклонённых мутаций нет.

Что взять: data/failure_log.jsonl (или расширить evolution_log) — на каждый облом/отклонённую правку писать корень, а не симптом. Прямо усиливает принцип CLAUDE.md «устранять причину, а не документировать баг».

3. Слой само-оценки — over-optimism («p-hacking / eureka-ing»)

Один из 6 failure modes статьи: модель объявляет успех на шуме, «numerical duct tape». У феанора anti-fabrication gate — про факты, но нет чека «не объявляй улучшение машинерии успешным без измеримого доказательства». Смыкается с п.1: «принято» = есть доказательство из gate, а не «кажется, стало лучше».

4. Слой безопасности — защитить editable surface

Статья: «если программа правит саму ОС, границы абстракции ломаются; permission/security-слой должен жить вне цикла эволюции». feedback_to_mutation технически может мутировать сами security-хуки → эволюция способна ослабить свои предохранители. Нужно явно объявить, что эволюция МОЖЕТ трогать (editable surface: скилы, скрипты, правила, CLAUDE.md-контент), а что НЕТ (security-хуки, permission-денаи) — и защитить второе.

Идеи «на вырост» (не сейчас, но держать в уме)

• Context as evolving playbook (ACE): держать знание как itemized bullets (id + описание), обновлять инкрементально, периодически дедуплицировать — НЕ переписывать блоб (риск context collapse / brevity bias). Мак-сторона memory/ уже так устроена (1 факт = 1 файл + frontmatter). Тот же дисциплинированный паттерн стоит строже применять к эволюции CLAUDE.md.
• Diversity в предложениях мутаций: Self-Harness требует «distinct and diverse» кандидатов. Эволюционный слот делает 1 правку/тик — можно генерить несколько разнообразных и отбирать (защита от diversity collapse, Challenge №4).
• Fuzzy evaluators (Challenge №1): самоулучшение работает там, где оценка измерима. Для «мягких» задач феанора (вкус, стратегия, легализация) — держать human-in-loop на правильном уровне абстракции (Challenge №7: человек поднимается вверх по стеку, а не выходит из петли). Для феанора это значит: высокие ставки → propose/ask, не auto (уже в CLAUDE.md — статья это подтверждает).
• Meta-Harness / DGM (дальний горизонт): оптимизировать сам КОД, решающий что хранить/показывать. Феанору рано, но направление: эволюционный слот со временем правит не контент, а механизмы.

Приоритет

1. Валидационный контур (п.1) — максимум пользы, закрывает ручной труд, фундамент для остального.
2. Rich failure log (п.2) — дёшево, сразу улучшает качество эволюции.
3. Anti-over-optimism (п.3) — надстройка над п.1.
4. Защита editable surface (п.4) — важно для безопасности по мере роста автономии.

Реализовывать по одному, каждое — через gate самого феанора (собственный принцип «фидбек меняет машинерию»). Не всё сразу — статья предупреждает про overengineering: «smarter models prevent harnesses from overengineering».

📌 Закладки — изучить позже

Harness Handbook: Making Evolving Agent Harnesses Readable, Navigable, and Editable

Кинул Даня 20.07.2026, источник: https://t.me/datastorieslanguages/708 (канал Data, Stories and Languages, #paperreview). ⚠️ Не изучено — только аннотация из поста, сам paper не читан.

Суть. Главное узкое место эволюции харнесса — behavior localization: запросы формулируются в терминах поведения («перестань выдумывать факты»), а репозиторий устроен по файлам и функциям. Решение — Harness Handbook: представление кодовой базы вокруг ПОВЕДЕНИЯ, а не структуры файлов. Трёхуровневое дерево (L1 обзор системы → L2 стадии и компоненты → L3 записи со ссылками на конкретный исходник) + state-register view для состояния, разделяемого между стадиями. Строится автоматически: статический анализ через tree-sitter без LLM → раскладка по стадиям через proposer-reviewer loop → синтез дерева. Правки идут сверху вниз через Behavior-Guided Progressive Disclosure.

Заявленные цифры (Terminus-2 и Codex, 60 запросов на модификацию, планировщик DeepSeek-V4-Pro, 3 LLM-судьи): win rate по качеству плана 45.6% vs 26.7% (Terminus-2) и 38.3% vs 28.3% (Codex); токенов планировщика МЕНЬШЕ на 8.6–12.7%; по локализации все 24 сравнения recall/precision/F1 в пользу handbook, F1 +5.0…+18.8. Слабый планировщик с handbook подбирается к локализации GPT-5.5 и Claude Opus 4.8.

Почему это прямо про нас. Ровно наша боль: фидбек Дани приходит в терминах поведения, а править надо в CLAUDE.md / .claude/rules/ / хуках / скриптах / скиллах — и каждый раз заново искать, где именно. Плюс две детали ложатся на наши уже принятые направления:
- resynchronization — после правок обновляются только затронутые части, а ссылки, которые больше не резолвятся, помечаются как stale, вместо молчаливого указания на неверный код. Это буквально наш «валидационный контур» + лечит протухшие next_step и мёртвые ссылки в скриптах (ср. script_reachability.py).
- state-register view — у нас состояние размазано по data/*.jsonl, MEMORY.md, pending_tasks.json; единого представления нет.

Открытый вопрос: строить ли handbook над харнессом феанора, или это overengineering для одного репо — статья сама предупреждает про overengineering. Решать после чтения самого paper.